Skip to content

[SYCL] Implement sycl_khr_queue_flush (old version, closed PR)#22158

Closed
HPS-1 wants to merge 5 commits into
intel:syclfrom
HPS-1:khr_flush_ext
Closed

[SYCL] Implement sycl_khr_queue_flush (old version, closed PR)#22158
HPS-1 wants to merge 5 commits into
intel:syclfrom
HPS-1:khr_flush_ext

Conversation

@HPS-1
Copy link
Copy Markdown
Contributor

@HPS-1 HPS-1 commented May 28, 2026 •
edited
Loading

Implement khr_flush() as per spec https://registry.khronos.org/SYCL/specs/sycl-2020/html/sycl-2020.html#sec:khr-queue-flush, which essentially issues all command in the queue to the device without waiting for them to complete. It seems that there's an existing UR function urQueueFlush() that achieves the "flushing" functionality, so I'm mostly reusing its code (in a new UR func urKhrFlush(), and I'm not directly using it due to the issue stated below).

However there's an issue that, for the OpenCL backend, urQueueFlush() is calling clFinish() (wait for commands to complete spec here) instead of clFlush() (doesn't wait for commands to complete spec here),
image
despite it clearly says its analogue is clFlush() in unified-runtime/source/loader/ur_libapi.cpp:
image
So I changed it in urKhrFlush() to call clFlush() instead. But not sure if it's a glitch or intended to use clFinish() for urQueueFlush(), can some reviewer from runtime kindly checks this out? If it's a glitch then I think we can just fix it and directly use urQueueFlush() for khr_flush()?

HPS-1 added 5 commits May 28, 2026 07:36
@HPS-1
[SYCL] Add khr_flush and respective UR code
ab8b355 
Signed-off-by: Hu, Peisen <peisen.hu@intel.com>
@HPS-1
[SYCL] Add L0 code
2d1e078 
Signed-off-by: Hu, Peisen <peisen.hu@intel.com>
@HPS-1
[SYCL] Add Intercept Funcs
b51972c 
Signed-off-by: Hu, Peisen <peisen.hu@intel.com>
@HPS-1
[SYCL] Squash all commits and format
3f03a26 
Signed-off-by: Hu, Peisen <peisen.hu@intel.com>
@HPS-1
[SYCL] Resolve merge conflict
aed838f 
Signed-off-by: Hu, Peisen <peisen.hu@intel.com>
@HPS-1 HPS-1 changed the title [WIP] [Do not merge] Implement sycl_khr_queue_flush [SYCL] Implement sycl_khr_queue_flush Jun 2, 2026
@HPS-1 HPS-1 marked this pull request as ready for review June 2, 2026 14:48
@HPS-1 HPS-1 requested review from a team as code owners June 2, 2026 14:48
@HPS-1 HPS-1 requested review from kweronsx and uditagarwal97 June 2, 2026 14:48
@gmlueck
Copy link
Copy Markdown
Contributor

gmlueck commented Jun 3, 2026

Please also updated this README.md file to include "sycl_khr_queue_flush" in the list of supported KHR extensions. The order of the extensions should match the order in Appendix F of the SYCL 2020 specification, so add "sycl_khr_queue_flush" after "sycl_khr_group_interface" and before "sycl_khr_work_item_queries".

@kswiecicki
Copy link
Copy Markdown
Contributor

kswiecicki commented Jun 3, 2026

Hey, I've created a fix for the opencl adapter urQueueFlush implementation here. I think that fixing the implementation to match the spec is more preferrable to introducing a new API that works around this issue.

@HPS-1
Copy link
Copy Markdown
Contributor Author

HPS-1 commented Jun 3, 2026

Hey, I've created a fix for the opencl adapter urQueueFlush implementation here. I think that fixing the implementation to match the spec is more preferrable to introducing a new API that works around this issue.

Thanks a lot for fixing it! (Also just to confirm you actually meant this PR #22202 right?) And yes I agree it would be better if we can just use the existing urQueueFlush now that it's fixed, rather than creating a new one. I'll update khr_flush() to use it instead.

@HPS-1
Copy link
Copy Markdown
Contributor Author

HPS-1 commented Jun 4, 2026

FYI I'm creating a new PR #22214 for the new implementation using urQueueFlush() to make commit history cleaner, so closing this one.

@HPS-1 HPS-1 closed this Jun 4, 2026
@HPS-1 HPS-1 changed the title [SYCL] Implement sycl_khr_queue_flush [SYCL] Implement sycl_khr_queue_flush (old version, closed PR) Jun 4, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@kweronsx kweronsx Awaiting requested review from kweronsx kweronsx is a code owner automatically assigned from intel/llvm-reviewers-cuda

@uditagarwal97 uditagarwal97 Awaiting requested review from uditagarwal97 uditagarwal97 is a code owner automatically assigned from intel/llvm-reviewers-runtime

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

3 participants

@HPS-1 @gmlueck @kswiecicki